home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-04-24 | 58.5 KB | 1,366 lines |
-
-
-
-
-
-
-
-
-
- Getting Started with TCP/IP on Packet Radio
-
-
- by John Ackermann, AG9V
- Miami Valley FM Association
- Dayton, Ohio
-
-
-
-
-
- 20 April 1992
-
-
-
-
-
-
-
-
- Copyright 1992 by John R. Ackermann, Jr.
- This document may be freely distributed in unaltered form for non-
- commercial use only, provided this copyright notice is included.
-
- *** Introduction ***
-
- This document is intended to help hams with some experience in
- packet radio get started with the TCP/IP software written by KA9Q
- and others. It is not intended to take the place of the software's
- reference manual, but rather to provide a quick-and-dirty
- introduction to the capabilities of TCP/IP and the mysteries of
- installing and using the software.
-
- There are several different versions of the KA9Q software floating
- around. It was originally written for MS-DOS computers, but has
- been ported to Macintosh, Amiga, Atari and UNIX systems. The
- original program was called "NET" and its last formal version was
- issued in April, 1989. If someone talks about "890421.1 NET,"
- that's what they're referring to.
-
- Since 1989, work has concentrated on a rewritten program called
- "NOS" (for Network Operating System, though confusingly the
- executable program for PCs is usually still called "NET.EXE"). NOS
- offers many new features that make using TCP/IP much more
- effective; you should use it instead of NET. However, NOS is a
- growing and changing creature; since there are several different
- versions, and they are being updated rapidly, I can't tell you
- precisely where to find the latest, greatest version. Your best bet
- is to check with a local user. If that doesn't work, there are
- several telephone BBS systems that carry various flavors of NOS:
-
- N8EMR's Ham BBS (614) 895-2553
- ChowdaNet (401) 331-0334
- WB3FFV (301) 335-0858
-
- The version I'm using, and which is reflected in this document, is
- PA0GRI's adaptation of NOS version 061891, as modified and
- distributed by N1BEE and available as "GRINOS" from the
- ChowdaNet BBS. I try not to dwell on features that are specific to
- this version, but if something I say doesn't seem to match your
- software, that's probably why.
-
- A last note before plunging in -- I said it before, and I'll say it
- again: this document barely scratches the surface of NOS. Nearly
- every command described here has options or parameters that I'm
- ignoring. My goal is to give you a feel for what TCP/IP does, and
- to get you on the air with NOS; to get beyond the novice stage
- you need to look at the reference manual and experiment with the
- software. Appendix A includes a list of organizations and
- individuals that can provide further information about TCP/IP and
- amateur radio.
-
- *** TCP/IP and Ham Radio ***
-
- TCP/IP is a set of communication protocols that have become a
- standard in the computer networking world. It is designed to link
- different kinds of computer systems together over dissimilar
- networks. TCP/IP software runs on nearly every kind of computer
- available, from IBM mainframes to PCs, Macs, Amigas, and Ataris.
- The KA9Q software (from now on, I'll call it "NOS") is special
- because it includes the features necessary to run TCP/IP over ham
- packet radio.
-
- The TCP/IP protocol suite allows different kinds of computers to
- talk to one another across networks. The services it provides
- include terminal sessions, file transfer, electronic mail, and data
- routing services. Computers running TCP/IP (referred to as
- "hosts") can run some or all of these applications simultaneously;
- it's entirely possible to sit at a PC computer running NOS and carry
- on a keyboard-to-keyboard chat with one station, while another
- retrieves a file from your hard disk and you send electronic mail to
- a third.
-
- It's also comforting to know that when you run TCP/IP, you don't
- give up the ability to carry on normal packet communications. You
- can use NOS just like a terminal program to establish connections
- with your local BBS or to chat with friends who don't run NOS
- (yet).
-
- If you've looked at the size of the NOS documentation, you're
- probably asking yourself what the benefit is of mastering this fairly
- complex stuff. Well, NOS has several features that improve on
- regular packet radio. It has much more sophisticated file transfer
- and electronic mail capabilities than our present PBBS systems
- (and it's possible to feed PBBS messages into NOS in a way that
- makes it much easier to use them). It supports multiple
- simultaneous connections. It has new and better transport
- methods that improve the reliability and throughput of slow and
- congested channels.
-
- NOS also has the ability to route transmissions to distant stations
- without the user needing to know every hop along the way; all
- you need to do is get your data to a "gateway" station that knows
- how to move it one hop closer to its destination. New work being
- done with NOS promises dynamic routing that automatically
- adjusts to changes in the network.
-
- And, since it is directly adapted from the de facto standard system
- of interconnecting computers, NOS offers the possibility of
- sophisticated services far beyond anything available on regular
- packet radio. For example, in some areas ham TCP/IP users can
- log into multi-user UNIX computer systems and run applications as
- if they were directly connected to those machines.
-
- *** What is TCP/IP? ***
-
- As mentioned above, TCP/IP is actually a set of protocols for the
- transfer of data across networks of computers. Two of these
- protocols underlie most of the others, and they give the set its
- popular name:
-
- TCP Transport Control Protocol, a "reliable stream service"
- (which is a fancy way of saying it makes sure that all the
- data sent to a remote host actually gets there), and
-
- IP Internet Protocol, which sets the basic rules for
- formatting packets of data to go out over a network.
- TCP rides on top of IP.
-
- Now that you finally know what "TCP/IP" stands for, there are a
- few concepts that are critical because they address a basic
- problem in any communications system -- identifying the parties to
- the conversation. Simply using our ham callsigns to address
- TCP/IP packets doesn't work for two reasons. First, the protocols
- work across many different networks, and have to have a
- consistent address scheme. Second, and as important, ham
- callsigns don't contain enough information to allow TCP/IP's
- sophisticated routing mechanisms to work.
-
-
- Names and Addresses
-
- The first important concept is the "IP Address." Since these
- protocols are used on lots of different computers, it is necessary to
- use an addressing system that works with all of them, that
- provides adequate routing information, and that doesn't take up a
- lot of space. The answer is to build addresses out of a four byte
- sequence of integers, with each byte providing information about
- the network and subnetwork(s) to which a host belongs.
-
- IP addresses are "hierarchical" because the four bytes have
- decreasing significance from left to right. By looking at the
- leftmost byte(s) we can learn how to route a transmission to the
- host represented by the rightmost byte(s). We usually print these
- addresses using the numeric value of each byte, separated by a
- period, such as [44.70.12.34]. This is known as "dotted
- notation." The square brackets aren't strictly necessary, but they
- are convenient to set off IP addresses; I'll use them that way in
- this document.
-
- I won't go into all the semantics of hierarchical addressing here,
- but as an example the address [44.70.12.34] breaks down as:
-
- 44. The network assigned to amateur radio TCP/IP.
- 70. The subnetwork for Ohio.
- 12. The Dayton/Cincinnati subnetwork.
- 34 A specific system address within that area.
-
- IP addresses are assigned by coordinators who derive their
- authority from a central registry. The coordinator for the ham
- radio net is Brian Kantor, WB6CYT. He has delegated authority to
- assign addresses to various state and national coordinators. The
- folks in Appendix A can help you find your local coordinator.
-
- The second important concept is the "hostname." Obviously, IP
- addresses aren't very intuitive. English-like hostnames make
- remembering addresses much easier, and TCP/IP programs,
- including NOS, have means (discussed below) to map between IP
- addresses and hostnames. A "host" is any computer running
- TCP/IP; even when you're using services from another computer,
- your system is still a host. When we talk about a "remote host,"
- we're talking about a machine that you're communicating with via
- TCP/IP.
-
- The convention in ham radio TCP/IP is to use your callsign as your
- hostname. To help reduce confusion, we usually print hostnames
- in lower case, and callsigns in capital letters -- my hostname is
- "ag9v," and my call is "AG9V" (though NOS isn't case sensitive
- and won't care if you don't do it this way).
-
- Closely related to the hostname is the "domain name." A
- "domain" is a group of machines that are logically (though not
- necessarily physically) connected together. Domain names are like
- IP addresses; periods separate parts of the name, with each part
- representing a different level in the domain hierarchy. But the
- domain name is ordered in reverse -- its highest-level portion is at
- the right, the opposite of IP addresses.
-
- The ham network's domain is "ampr.org"; "org" (short for
- "organizations") is the top level domain, and "ampr" (for AMateur
- Packet Radio) is the second level domain, containing all ham
- TCP/IP hosts.
-
- When you combine a hostname with a domain name, you get
- something like "ag9v.ampr.org." This is called a "Fully Qualified
- Domain Name" ("FQDN" -- knowing this acronym allows you to
- sound like a real expert). If a host has multiple users, we can add
- the user's login name at the beginning of the address, separated
- from the FQDN by a "@" character. This combination is
- commonly known as an "Internet address" (the "Internet" is the
- general term for all the TCP/IP hosts that are interconnected) and
- is the address form used for most electronic mail in the real world.
- For example, if there is a user "jra" at ag9v, "jra@ag9v.ampr.org"
- would be that user's full Internet address.
-
- There's one last twist. Some services (such as Domain Name
- Service, discussed below) need to know whether an address they
- are processing is in fact an FQDN. To do so, they look for a
- trailing period at the end of the domain name. Some versions of
- NOS ignore this issue, but the PA0GRI versions (such as GRINOS)
- insist that you "anchor" all domain names with a period at the end
- of the name. In other words, GRINOS will barf if you issue the
- command "hostname ag9v.ampr.org" but "hostname
- ag9v.ampr.org." will make it happy.
-
- This may seem like an overly complicated scheme to simply allow
- two hams to talk to each other, but we use it because the ham
- radio TCP/IP network can be tied to the worldwide TCP/IP network
- in a number of different ways, and using the full set of TCP/IP
- address conventions makes it possible for traffic to flow between
- the ham network and the real world.
-
- Leaving aside legal issues about third-party traffic, there's no
- reason, for example, why electronic mail can't be automatically
- routed through a "gateway" (a computer that interconnects two or
- more networks) between a ham TCP/IP user and a non-ham who
- has access to the Internet. In fact, this service already exists in
- some areas.
-
- The good news is that for traffic within the ham network, we only
- need to worry about hostnames, and NOS's "domain suffix"
- command will take care of adding the "ampr.org" extension for us;
- we only need to deal with the full details of addressing if we want
- to go outside the ham radio network.
-
-
- TCP/IP Services
-
- Now that we have those boring basics out of the way, the
- protocols that use TCP/IP to provide real, useful services include:
-
- TELNET The terminal emulation program. In "real" networks,
- telnet lets a user at one host remotely access a remote
- host, just as if he was on a terminal directly connected
- to that computer. In NOS, the telnet function usually
- connects you to a remote host's mailbox, which acts
- very much like a personal PBBS. The NOS telnet
- command does allow you to remotely login to a host that
- supports that function; in some areas UNIX computers
- connected to the ham TCP/IP network provide that
- service.
-
- FTP File Transfer Protocol. A means of transferring both
- ASCII (text) and binary (program, data, or compressed)
- files between hosts.
-
- SMTP Simple Mail Transfer Protocol. A (mostly) invisible way
- of moving electronic mail from one host to another. If
- you create a message on your computer (using the BM
- program, discussed below), SMTP will automatically
- attempt to transfer it to the destination computer.
-
- POP Post Office Protocol. SMTP is neat, but it's really
- designed to work with hosts that are available full time.
- Most ham TCP/IP stations aren't. POP is designed for
- them; it allows incoming mail to be stored at a host that
- acts as a "mail server;" when you come on the air, your
- system automatically asks the server to send you your
- mail.
-
- PING Packet InterNet Groper. A diagnostic that sends a packet
- to a specified host; if the host is accessible to you and
- on the air, it responds with another packet. PING tells
- you how long the round trip took.
-
- FINGER A way of finding out information about the users at a
- host. The finger command can simply list all the users at
- a host, or spit out information (like the "brag tape" of
- RTTY days) about a specific user.
-
- ARP Address Resolution Protocol. IP addresses need to be
- matched with the correct hardware address (in our case,
- ham callsign) to allow packets to be sent to their
- destination -- NOS doesn't know what callsign goes with
- a given IP address. ARP does this by sending out a
- broadcast message when it needs to know the callsign
- that matches an address. The remote host (if it's on the
- air) will answer and provide its hardware address.
-
- DNS Domain Name Service. Remembering IP addresses isn't
- easy. NOS can use a file called "DOMAIN.TXT" to
- contain mappings between hostnames and IP addresses,
- but that means you need to know the hostname and
- address of any station you want to contact.
- Alternatively, a remote host may agree to serve as a
- "domain name server" that NOS can query when it needs
- to know the address of a host. Not all areas have a
- name server available to the ham community, but in
- those that do, life is a lot easier.
-
- *** Installing NOS ***
-
- Frankly, there's no completely painless way to get NOS running on
- your computer. NOS is somewhat picky about the directories used
- for its files, and there are a number of custom parameters that you
- must set to teach the program about your environment and your
- network. Those parameters are contained in a configuration file
- that most versions of NOS call "AUTOEXEC.NET" (PA0GRI
- versions use "AUTOEXEC.NOS;" our references to
- "AUTOEXEC.NET" mean whichever name is appropriate).
-
-
- Files and Directories
-
- You should create the following directories on your disk (NOS can
- work from either a hard disk or a floppy; it's getting big enough,
- though, that working from a 360K floppy can be tough):
-
- \spool (holds NOS' working files)
- \spool\help (help files for the mbox)
- \spool\mail (mail messages go here)
- \spool\mqueue (mail workfiles)
- \spool\rqueue (incoming mail workfiles)
- \finger (home for finger info files)
- \public (file uploads/downloads)
-
- These files need to go in the root directory of your default disk (it
- is possible to configure NOS to look for these files in other than
- the root directory; see the reference manual for details):
-
- AUTOEXEC.NET (the NOS configuration file)
- FTPUSERS (user ftp/mbox access)
- DOMAIN.TXT (hostnames)
- BM.RC (mail program configuration)
- ALIAS (used by smtp and BM)
-
- NOS uses two executable files. These can be installed anywhere
- on your file path:
-
- NET.EXE, NOS.EXE, or GRINOS.EXE (main executable)
- BM.EXE (mailer program)
-
-
- Setting up AUTOEXEC.NET
-
- Once the directories are created and the files copied, you need to
- edit the AUTOEXEC.NET file with a text editor to customize it. A
- sample file is included as Appendix B. Some of the things you'll
- have to put in the file are:
-
- Your hostname (usually your callsign in lower case):
- hostname ag9v.ampr.org.
-
- Your IP address:
- IP address [44.70.12.34]
-
- Your callsign (optionally including an SSID; local customs vary on
- this):
- ax25 mycall AG9V
-
- "attach" commands to tell NOS how to talk to your hardware.
- These can get quite hairy; Appendix C has the details. For a TNC
- on COM 1 at 4800 baud serial port speed, use:
- attach asy 0x3f8 4 ax25 ax0 1024 256 4800
-
- The "ax0" in the middle of the command is the "interface" name --
- you use it to identify this port to NOS when you set up routing
- commands and the like. You can use any (short) name you'd like,
- but the convention for COM ports is to use ax0, ax1, etc.
-
- At least one routing command. NOS needs to know where to
- send packets. A default route that sends all packets out the ax0
- interface is:
- route add default ax0
-
- If you have a gateway for packets going outside the local area,
- include a route like:
- route add [44.70.13.0]/24 ax0 ag9v
-
- This command would route packets addressed to any host with
- "44.70.13" as the first three bytes of its address out the ax0
- interface to ag9v, which presumably knows how to get these
- packets to their destination. The "/24" means that the first 24 bits
- (three bytes) of the address are significant; NOS will ignore the
- last byte when making routing decisions.
-
- If you have a domain name server, add a command near the
- beginning of your configuration file identifying its IP address:
- domain addserver [44.70.12.34]
-
- If you have a local mail server that knows how to route messages
- outside the area (see the discussion of electronic mail, below), add
- a command identifying it:
- smtp gateway [44.70.12.34]
-
-
- Storing Name/Address Matches in DOMAIN.TXT
-
- If you don't have a local domain name server (DNS), you'll need to
- create "DOMAIN.TXT" in the root directory, with one entry for
- every hostname you want to communicate with. Appendix D
- shows how to set up this file. If you don't have an entry for a
- host in the file (or the name server doesn't know about it), you
- can use the IP address instead of the hostname in NOS
- commands.
-
- If you're using DNS, NOS will save the hostname/address matches
- it gets from the server in DOMAIN.TXT, so you'll find that file
- existing (and growing) even if you didn't create it.
-
- Giving the Finger
-
- If you want users to be able to learn about your station with the
- finger command, you need to create a text file in the \finger
- directory called <hostname>.txt (by the way, when we use angle
- brackets like this, it means this is a value you'll need to insert
- yourself -- minus the angles -- based on your own configuration).
- You can use any ASCII text editor to create the file; it should
- contain basic info about your system. Don't go overboard... one
- screen of text is plenty.
-
- You can also create additional files with information about specific
- aspects of your system. For example, you might have a list of the
- files available for downloading on your system in a finger file called
- "filelist.txt." A remote host who issues the command "finger
- filelist@<myhost>" will get that list.
-
-
- Some Boring but Necessary Technical Stuff
-
- Before we move on to the good stuff about how to make NOS do
- magic, we need to talk about three related commands that you
- may need to tweak depending on local custom and the quality of
- the RF paths you're using. Just as regular AX.25 uses the
- "paclen" command to limit the size of packets, TCP/IP has
- parameters defining how much data is moved in one chunk. In
- theory, the larger the datagram (TCP/IP's term for a single block of
- data), the higher the efficiency, because the protocol headers add
- a fixed amount of overhead; in larger datagrams the overhead is a
- smaller percentage of the total data sent.
-
- However, some networks (such as NetRom) can't handle large
- datagrams in one piece. More importantly, the larger the
- datagram, the longer it takes to transmit, and on a busy or flaky
- path, the greater the likelihood that something will corrupt it along
- the way. And, it takes longer to resend a large packet than a
- small one, so the cost of retries is greater. Because of these
- factors, a fast network with clear channels and solid paths can get
- away with sending much larger datagrams than a slow, unreliable
- one.
-
- NOS provides three parameters that deal with datagram sizes. The
- most important one is the "mtu" (the sixth value in the "attach
- asy" command described above). It is similar to paclen; it sets the
- largest packet, including any headers, that can be sent on an
- interface. Datagrams larger than the mtu are fragmented into
- multiple pieces, which seriously reduces efficiency. Each interface
- has its own mtu, set as part of its attach command.
-
- For 1200 baud channels that are shared with other packet users,
- an mtu value of 256 is reasonable; in fact, since that is the largest
- packet size most non-TCP/IP ham networks (like digipeaters and
- NetRom) are designed to handle, 256 is the largest mtu you should
- specify if any of your packets are going to travel via such a node.
-
- Faster networks may use higher values. For good-quality channels
- with fast data rates (9600 baud or above), it may be reasonable to
- use an mtu ranging from 512 to 1500 (which matches the
- standard mtu used by ethernet systems).
-
- The other two parameters that set datagram size are part of the
- TCP protocol. "tcp mss" (maximum segment size) is the largest
- chunk of data that TCP will send in a single frame. Because the
- TCP and IP headers attached to each datagram total 40 bytes, mss
- should be 40 bytes smaller than mtu; 216 is the correct value for
- an mtu of 256.
-
- The "tcp window" parameter tells NOS how many datagrams it
- can have outstanding at once -- if it is twice the value of mss,
- NOS can receive two datagrams before sending an
- acknowledgment. This parameter is analogous to the "maxframe"
- parameter in AX.25. A large window improves efficiency because,
- among other things, multiple acknowledgments can be sent in a
- single packet.
-
- Although using a large window has major benefits on full duplex
- networks, on typical ham networks best performance comes from
- smaller windows ranging from one to three times the mss. A good
- starting point is to set the window equal to twice the value of mss
- (432 for an mss of 216).
-
- In summary, good starting points are:
-
- 1200 baud, shared channel: 9600 or faster, clear channel:
- mtu 256 mtu 1500
- tcp mss 216 tcp mss 1460
- tcp window 432 tcp window 2920
-
-
- Even more than in other parts of this manual, this discussion
- glosses over lots of subtleties. Throughput can be drastically
- affected by tuning these values, and both experimentation and
- local consensus are necessary to come up with settings that work
- well without stomping on other users of the channel.
-
- *** Using NOS ***
-
- To run NOS, first make sure you have your TNC configured for
- "KISS" mode (see Appendix F for details) and turned on. Then,
- type NET, NOS, or GRINOS (as appropriate). In a few seconds,
- you should see a "net>" prompt. Any error messages that appear
- first probably indicate a problem with one or more commands in
- your AUTOEXEC.NET file.
-
- When you see the prompt, NOS is in "command mode." When
- you are communicating with another host, NOS is in "converse
- mode." To return to command mode from converse mode, press
- the F10 function key (sometimes called the "escape" key, but not
- to be confused with the "ESC" key on your keyboard). All
- commands typed at the NOS prompt need to be followed by the
- return key.
-
- Typing "?" in command mode will display a list of commands.
- Typing a command name followed by ? will display the valid
- subcommands. You can't really call it a help system, but it's
- better than nothing.
-
- Some commands can be abbreviated to save typing; the degree of
- abbreviation allowed depends on the command set of the NOS
- version you're using. Experimentation is the best way to see what
- works and what doesn't. One minor annoyance in GRINOS is that
- commands are case sensitive -- "c ax0 n8acv" is fine, but "C ax0
- n8acv" isn't. It's safest to do all your NOS keyboarding in lower
- case -- apart from case sensitive commands, in the Email world,
- typing in all upper case is considered shouting!
-
- You can issue several commands from within NOS to deal with
- files and directories. "pwd" displays your current working
- directory, and "cd" allows you to change directories. "dir"
- displays files in the current directory. "mkdir <dirname>" creates
- a new directory, and "rmdir <dirname>" removes one. "delete
- <filename>" erases a file.
-
- You can also "shell out" to DOS from within NOS by entering
- either an exclamation mark (!) or the command "shell." To return
- to NOS, type "exit" at the DOS prompt.
-
- From command mode, you can start a number of different types of
- sessions to communicate with remote hosts. Each session has its
- own display screen and you can switch between a session and
- command mode, or between sessions. The se command displays
- the active sessions with identifying numbers. To switch to a
- session, you can type "se <session number>." From command
- mode, you can return to the current (most recently displayed)
- session by entering a carriage return.
-
- You can capture incoming data from the current session to a disk
- file by using the "record <filename>" command, and you can
- read in a data file from disk with the "upload <filename>"
- command.
-
- To close a session, press F10 to return to command mode and
- enter "close <session number>." If there's only one session
- open, you can just enter "close." You can also end the session by
- issuing the appropriate exit or quit command at the remote host's
- prompt.
-
- The most common NOS session types are probably "telnet," its
- cousin "ttylink", "ftp," and a regular packet "connect" (technically
- called an "ax25" session). Telnet is used to "login" to a remote
- host, ttylink is a kind of telnet specially designed for keyboard-to-
- keyboard communications, ftp handles file transfers, and ax25
- sessions allow you to carry on normal packet activity. We'll talk
- about ax25 sessions first, since they give you a chance to test
- your setup without having another TCP/IP station on the air.
-
-
- AX.25 Mode
-
- The "connect" command simply lets you do normal packet radio
- stuff. Establishing an ax25 connect through NOS is like using the
- standard TNC commands with a few small differences. First, since
- NOS can support several interfaces, each with its own hardware,
- you need to tell NOS which one to use.
-
- So, to connect to N8ACV on interface ax0, enter "connect ax0
- N8ACV." Once you get a "Connected" message, you'll be able to
- type to the station at the other end just as you would with normal
- packet. In addition to closing the session as described above, you
- can exit an ax25 session by typing "disconnect" at the command
- mode prompt. (Just as with a TNC, these commands can be
- abbreviated; just how few of the letters are necessary will depend
- on each implementation of NOS and the commands it supports).
-
- The other minor difference between the NOS connect command
- and a regular TNC is that the word "via" is not used when
- specifying digipeaters. To connect to N8ACV through N8KZA on
- interface ax0, you would enter "connect ax0 N8ACV N8KZA."
-
-
- Telnet
-
- The "telnet" command logs you in to a remote TCP/IP host;
- depending on the capabilities of that host, you might find yourself
- chatting directly with the user at the other end, connecting to the
- NOS mailbox, "mbox" (which acts very much like a sophisticated
- personal PBBS), or getting a UNIX "login:" prompt. To establish a
- telnet session, enter "telnet <hostname>" at the command
- prompt.
-
- Some versions of NOS offer a new type of session that improves
- on telnet for real-time keyboard-to-keyboard chats. It's called
- "ttylink," and it works just like telnet (for example, start a session
- with "ttylink <hostname>") except that it connects you directly
- to the remote host's chat mode, and uses a split-screen format to
- make things less confusing as you type to each other.
-
- You'll get a message like "Telnet session 1 failed: Reset/Refused
- errno 9" if the remote host doesn't support ttylink. If the operator
- at the other end isn't available to chat, you'll get a message like
- "The system is unattended." You'll still be able to type, but there
- won't be anyone there to reply. You can change the status on
- your machine by setting the "attended" command to either on or
- off. You might want to put this command in your AUTOEXEC.NET
- file to set your default status. You exit from ttylink just as you
- would from telnet.
-
- And now a note from Miss Manners: you should never simply exit
- from the NOS program when you have an open session. Doing so
- can cause great unpleasantness at the remote host. Unless you're
- in some sort of software or hardware lockup, or you know that the
- station on the other end has gone away, always close sessions
- and wait for confirmation before exiting the program.
-
- You should also be aware that your system may have started
- sessions in the background, for example to transfer electronic mail,
- or someone else may have started a session with your system.
- You may not even know these sessions are running. Pulling the
- plug on them would be very impolite. Before exiting NOS, you
- should first use the se command to make sure there are no current
- sessions running, and then the "tcp status" command to see if
- there are any background connections established. "tcp status"
- will show you a long and confusing list of information; the
- important stuff at the end is the list of sockets (which are services
- your system can either offer or request on the network). If
- anything other than "Listening" appears in the Status column, that
- means there's at least one remote host communicating with you.
-
-
- File Transfers
-
- You initiate a file transfer (ftp) session by entering "ftp
- <hostname>" at the command prompt. Once the session is
- established, the remote host will prompt you for a user name and a
- password. If your hostname and password have been added to
- the remote host's FTPUSERS file, you'll have the ability to
- download and perhaps upload files in the directories permitted you.
-
- If you haven't arranged with the remote host for your own
- account, you can try to login as "anonymous" or "guest;" many
- systems support these user names and grant limited (usually
- download-only) privileges to them. If you login under one of these
- accounts, you should enter your hostname as the password; that
- allows the remote host to keep track of who's been using the
- system.
-
- Once you've logged in, you'll see a new prompt: "ftp>." This will
- remind you that you're actually issuing commands to the remote
- computer. From the ftp> prompt, you can list the files in a
- directory, change directories, upload files, or download files.
-
- To list files, enter "dir" at the ftp> prompt. You will get a listing
- that shows subdirectories (if any) and files together with their
- dates and sizes. To show the current directory name, type "pwd."
- To change directories, issue the "cd <directory>" command.
- Note that directories are displayed with a forward slash (/) instead
- of the usual MS-DOS backslash (\). That's because the UNIX
- operating system, which is TCP/IP's natural home, uses forward
- slashes. If the remote host is running NOS, you can use either
- character, but some other systems (particularly those running
- UNIX) will recognize only the forward slash.
-
- Once you've found a file you want to upload or download, you
- need to make a decision. ftp can transfer the file either as an
- "image" file, byte for byte, or as an "ascii" file, converting the line-
- end character as necessary to compensate for different operating
- systems (UNIX uses only a linefeed character at the end of lines;
- MS-DOS uses carriage return/linefeed). Before beginning a file
- transfer, enter "type i" for an image file, or "type a" for an ASCII
- file, at the ftp> prompt.
-
- What are the consequences choosing the wrong transfer type?
- Well, transferring a binary file as type "a" will almost certainly fail.
- Transferring an ASCII file as type "i" will work, but you may find
- that the line-ends are screwed up. ASCII transfers are also quite a
- bit slower than image, because each line needs to be processed
- separately.
-
- To actually start a file transfer, use the command "put <local
- filename> <remote filename>" to send a file, or "get <remote
- filename> <local filename>" to receive one. The file name can
- include a full path if you desire; remember to use the proper path
- separator character for the remote host.
-
- If you only specify one filename, ftp will assume that both the
- local and remote hosts will use the same name. This can be
- dangerous if the remote host uses a different operating system
- than you do, as it may have filenames that are illegal on your
- system.
-
- If a file transfer goes awry, you can terminate it by going to
- command mode via F10 and issuing the "abort" command. To
- end an ftp session, you can either type "quit" at the ftp> prompt
- (the preferred way), or you can close the session from the net>
- prompt.
-
- If you want others to be able to access files on your system, you'll
- need to set up an FTPUSERS file in your root directory. Appendix
- E describes the contents of that file.
-
- Another message from Miss Manners: transferring files via ftp is
- reliable, but can be slooooow, particularly at 1200 baud. Before
- you start downloading a 250 kilobyte file, consider how busy the
- channel is, and whether you want to tie things up for (perhaps)
- several hours by your download. NOS is polite and won't hog the
- channel, but don't doubt that a large file transfer will slow things
- down for everyone else.
-
- Other Protocols
-
- The "ping" protocol mentioned above is very useful to see if a
- remote host is on the air. Just enter the command "ping
- <hostname>" at the NOS prompt. If the host is available, you
- will see a response indicating what the round-trip time was to that
- host. The time may be many seconds if you're going through
- gateways, so be patient.
-
- The "finger" protocol lets you see information about a remote
- host's users and services. Entering "finger @<hostname>" (note
- the slightly different syntax -- the "@" symbol must immediately
- precede the remote hostname) will display a list of the finger files
- (described above) at that host. Entering "finger
- <user@hostname>" will display the text file for that user.
-
-
- *** Electronic Mail ***
-
- We've saved NOS's electronic mail capabilities for last because
- they are a bit more involved than some other parts of the program.
- You use two programs to handle mail: BM (a "user mail agent," in
- UNIX terms) to write and read messages, and NOS to send and
- receive them. First we'll talk about reading and writing messages,
- and then about using NOS to transport them.
-
-
- Using BM.EXE to Read and Write Messages
-
- BM.EXE is a program that reads and writes mail message in the
- format TCP/IP systems recognize. Contrary to popular belief,
- "BM" stands for "Bdale's Mailer" in honor of its creator, Bdale
- Garbee. You can run BM from the DOS prompt just like any other
- program, from within NOS by shelling to DOS with ! or shell, or (in
- GRINOS) by typing the mail command from the net> prompt.
-
- Before using BM, you need to create its configuration file, BM.RC,
- which must live in the root directory of your disk. An annotated
- BM.RC file is included as Appendix G. Only the first three
- commands in the sample file are absolutely necessary to make BM
- work.
-
- There's a bit of controversy in some areas over the proper name to
- enter for "user" in BM.RC. Some folks recommend using either
- your first name, or your initials (for example, my address would be
- "john@ag9v.ampr.org") while other suggest using the callsign
- instead ("ag9v@ag9v.ampr.org").
-
- While using the callsign may seem more impersonal, it has major
- advantages when mail is moving between TCP/IP and the packet
- BBS system, or when using the POP server; we strongly
- recommend that you use the "callsign@hostname" format unless
- the locals object even more strongly. It's important to be
- consistent within the area, so that everyone knows how to
- address mail to everyone else.
-
- When you start BM, you'll see a prompt such as "ag9v>"
- showing the default mailbox (based on the "user" entry in BM.RC).
- As in NOS, you enter commands at the prompt, following them
- with a carriage return. Most BM commands are single letters,
- optionally followed by a mail addressee or a message number (or
- numbers).
-
- To send mail, use the command "m <addressee>." The
- addressee will normally be a user at a remote host; for example,
- ag9v might send mail to k8gkh@k8gkh. The single biggest
- problem with BM is forgetting to include the hostname -- in other
- words, sending mail to <user> rather than
- <user>@<hostname>. Without the hostname, BM will think
- the user is on your local system, and the mail will end up being
- stored in a mailbox under that user's name on your own system.
- That doesn't work too well.
-
- One way to solve that problem, and do some other interesting
- things, is to create an ALIAS file in your root directory. When you
- send a message, BM will compare the addressee with the alias file,
- and if it finds a match will replace the alias with a full address from
- the file. An alias can point to a list of addresses, so it's possible
- to define an alias that will send a copy of the message to everyone
- in your local group. A sample alias file might look like:
-
- greg k8gkh@k8gkh.ampr.org
- bill n8kza@n8kza.ampr.org
- club k8gkh@k8gkh.ampr.org n8kza@n8kza.ampr.org
- n8acv@n8acv.ampr.org wb8gxb@wb8gxb.ampr.org
-
- The alias for "club" demonstrates two things: a single alias can
- expand to several addresses, and you can continue a long address
- list on subsequent lines by indenting them with spaces or a tab
- character.
-
- Now, if you send mail to "greg" it will automatically be expanded
- to the full address, and by sending a message to "club" all four
- users will get a copy.
-
- By the way, you do not use a trailing dot after an FQDN (as
- discussed above) in Email addressing; doing so will screw things
- up.
-
- If you use BM's built-in editor to compose messages, remember
- that it doesn't wrap lines; you have to hit the carriage return at the
- end of each line. Use the "l" command to list outbound mail; you
- can kill an outbound message with the "k <msg#>" command,
- using the message number obtained from the "l" command.
-
- Several commands are used to deal with incoming mail. "h"
- displays the headers (summary info) about messages in your
- mailbox. It is the basic command you should use to check your
- incoming mail. Each header displayed includes a message number
- to use with the other message manipulation commands.
- Commands given without a message number act on the current
- message (the one marked with an ">" in the display from the "h"
- command); if there's only one message, it is always the current
- one.
-
- BM can support multiple users at a single host; a separate mailbox
- is created for each user. Unfortunately, BM has no way of
- knowing if incoming mail addressed to <someuser>@<yourhost> is
- valid, so it will happily accept such mail and create a new mail-
- box for <someuser>. You may never know it's there, unless you use
- the "n" command to display the list of mailboxes. You can also use
- "n" to change to a different mailbox: "n <mbox>."
-
- The commonly used commands (which may be followed by one or
- more message numbers if appropriate) are:
-
- msg# message number by itself will display that message and
- set it as the current message.
- r reply to a message.
- d delete a message.
- s save a message; if a file name follows the message
- number(s), the message(s) will be saved in that file.
- Otherwise, they'll be saved in the default mbox file.
- u undelete a message previously marked for deletion.
- p print a message on the local printer.
- w save a message to a file without including headers.
- f forward a message to another recipient.
- b bounce a message. Like forward, but keeps the original
- sender information intact (i.e., the message will not
- appear to have been sent by you).
- $ update the mailbox. This deletes messages marked for
- deletion and reads in any new mail that may have arrived
- since you started BM.
-
- There are two commands that exit from BM: "x" will exit without
- updating the mailbox. In other words, the same messages will be
- there the next time you run the program. "q" updates the mailbox
- (like "$") and then exits.
-
- Outbound mail created by BM is stored in the \spool\mqueue
- directory, where it waits patiently until one of NOS's servers
- (SMTP or POP) attempts to send it to its destination.
-
-
- Moving Mail With NOS
-
- Now, to the mechanics of getting mail into and out of your
- system. All mail that you create is sent to its destination (or at
- least to the next stop on the way) by the "smtp" server in NOS.
- The "smtp timer" command (set in AUTOEXEC.NET) tells smtp
- how often to scan the \spool\mqueue directory for outgoing mail.
- When it finds some, it attempts to open an smtp session to the
- remote host in the address and send the mail there. There's no
- default for the smtp timer value, so your AUTOEXEC.NET file
- should include something like "smtp timer 600" (which scans for
- mail every ten minutes). You can manually force smtp to scan the
- queue by issuing the "smtp kick" command from the net> prompt.
-
- If you have a local mail server with connections to the outside
- world, you can use it to route mail for hosts that aren't in your
- domain file with the "smtp gateway <hostid>" command.
-
- Incoming mail can arrive at your station when a remote host does
- this and starts an smtp session with you. But if you don't keep
- your station up 24 hours a day, the remote host will be trying, and
- trying, and trying, to connect with you until you finally show up.
- A far better approach is to use "POP" -- the Post Office Protocol.
- If your system runs POP, and someone in the area has agreed to
- be a POP server, NOS will automatically contact that server when
- you come on the air; the server will respond by sending the mail
- waiting in your mailbox. You can then read it with BM just as if it
- had arrived via smtp.
-
- To use POP, the server must establish a mailbox and password for
- you, and you need to add the appropriate commands to your
- AUTOEXEC.NET file (see the annotated AUTOEXEC.NET file in
- Appendix B).
-
- Remember that smtp or POP sessions may be running in the
- background without your knowing about it. Always check for
- activity with the "tcp status" command before pulling the plug!
-
- Additionally, smtp creates lock files in \spool\mqueue when it tries
- to send outgoing mail. If NOS is killed before the mail transfer has
- succeeded, these files (with the extension ".LCK") will be left
- behind and if they are not manually removed, they will prevent
- smtp from trying again to send those messages. To prevent this,
- you should always issue the command "erase \spool\mqueue\*.LCK"
- before starting NOS. It's a good idea to launch NOS using a batch
- file that removes the locks before executing the program.
-
- *** Conclusion ***
-
- This has been a whirlwind tour of TCP/IP. Once you have the
- software installed, it's not hard to use, and NOS truly opens the
- door to enjoying packet radio in a whole new way.
-
- To learn the subtleties of NOS, you should do two things: read
- the reference manual for the version you're using, and experiment
- with the program. Once you know the ins and outs, please share
- your knowledge with others. The ham radio TCP/IP community is
- still small, and we need all the Elmers we can get!
-
-
- John Ackermann AG9V
- 2371 Stewart Road
- Xenia, OH 45385
-
- TCP/IP: ag9v@ag9v.ampr.org. [44.70.12.34]
- PBBS: AG9V@N8ACV.OH.US.NA
- Internet: jra@lawday.daytonOH.ncr.com
- CompuServe: 72300,1160
-
-
- APPENDIX A
- Resources for NOS and TCP/IP
-
- (Note: This is a very incomplete list; please feel free to provide
- additional resources to add for the next edition!)
-
- TAPR
- P.O. Box 22888
- Tucson, AZ 85734
-
- The New England TCP Association
- 3628 Acushnet Ave.
- New Bedford, MA 02745
-
- APPENDIX B
- Sample AUTOEXEC.NOS File for GRINOS
-
- # AUTOEXEC.NET
- # This is a sample autoexec file for GRINOS version N1BEE 0.72.
- # It doesn't have all the fancy features one might hope for, but
- # the basics are there, with some hopefully useful comments.
- # Any line beginning with a "#" character is treated as a comment.
- # To uncomment a line, delete the # character
-
- # These are a couple of things for NOS to use internally.
- mem eff on
- watchdog on
- nibufs 10
-
- # NOS needs to know three things about you: your hostname,
- # your ham callsign, and your IP address. By convention, the
- # hostname # is your callsign in lower case, followed by ".ampr.org".
- # The callsign is generally used in upper case to distinguish it.
- # The IP address comes from a local area coordinator. Note that
- # there are a minimum of three places in this file where you need to
- # insert your IP address -- here, in the ifconfig command, and at the
- # end of each attach command.
- hostname nocall.ampr.org
- ax25 mycall NOCALL
- ip address [44.xx.xx.xx]
-
- # This should match your IP address
- ifconfig loopback ipaddress [44.xx.xx.xx]
-
- # This makes short forms of the hostname work.
- domain suffix ampr.org.
-
- # NOS needs to know how to convert hostnames to IP addresses.
- # You can do this manually via the "DOMAIN.TXT" file, or you can
- # use a nameserver if one is available. To enable the
- # nameserver, uncomment this line and plug in its correct
- # address.
- #domain addserver [44.xx.xx.xx]
-
- # Some additional commands for the domain service. Don't turn
- # translate on unless you have a small domain file and/or a fast machine.
- domain verbose off
- domain cache size 40
- domain translate off
-
- # To use POP, uncomment these lines. Fill in "pop mailhost" with
- # the IP address of the station serving as your POP server. Fill in the
- # "pop# mailbox" name with your hostname, i.e., your call. The "pop
- # userdata" line needs to have your hostname, followed by a password
- # (as negotiated with your mail server). "pop timer" sets
- # how often, in seconds, to query for mail.
- #pop mailhost [44.xx.xx.xx]
- #pop mailbox hostname
- #pop userdata hostname password
- #pop timer 1800
-
- # Attach commands are complex; these are samples for COM 1
- # and 2. See Appendix C for details. Uncomment the
- # appropriate line(s) for your hardware.
- # COM1 -- 256 byte MTU, 4800 baud serial link as ax0
- attach asy 0x3f8 4 ax25 ax0 2048 256 4800
- # COM2 -- 256 byte MTU, 4800 baud serial link as ax1
- #attach asy 0x2f8 3 ax25 ax1 2048 256 4800
-
- # This is the basic route, sending everything out ax0
- route add default ax0
-
- # These are tcp parameters you shouldn't need to mess with.
- ip ttl 16
- ip rtimer 240
- tcp irtt 3000
-
- # On a shared channel, you may want to change timertype to
- # exponential; that's more courteous, but will slow your
- # retries down significantly. mss and window should ordinarily be
- # the same value, equal to the largest mtu set in the attach
- # command(s) above minus 40. With the common mtu for 1200 baud
- # channels of 256, that means both mss and window should be 216.
- tcp timertype linear
- tcp bblimit 16
- tcp mss 216
- tcp window 216
-
- # These set up AX.25 parameters
- ax25 digipeat off
- ax25 maxframe 1
- ax25 paclen 256
- ax25 retry 20
- ax25 window 4096
- ax25 blimit 15
- ax25 version 2
-
- # as with tcp timertype, you may want to set this to
- # exponential on a shared channel.
- ax25 timertype linear
-
- # These are netrom setup commands. Don't turn them on
- # unless you need them, and you know what you're doing. You
- # can really screw up the network by putting out netrom
- # broadcasts that don't fit with the configuration of the
- # "real" netrom nodes that can hear you.
- #attach netrom
- #netrom interface ax0 MYALIAS 192
- #netrom obsotimer 1800
- #netrom nodetimer 10800
- #netrom verbose yes
- #netrom bcnodes ax0
- #netrom ttl 8
-
- # These start the servers.
- start smtp
- start ftp
- start echo
- start discard
- start telnet
- start finger
- start ax25
-
- # Uncomment this line to enable logging.
- #log \spool\net.log
-
- # Default file type for ftp transfers. Type image is for binary files;
- type
- # ascii is for text; it's safest to set the default to image.
- ftype image
-
- # This makes telnet sessions to Unix systems work
- # line-by-line, rather than character-by-character.
- echo refuse
-
- # Tell smtp how often to scan for outgoing mail
- smtp timer 600
- smtp batch on
-
- # GRINOS can send a string of commands to the TNC on startup.
- # You could use this to force the TNC into KISS mode. Note that
- # you need to specify which interface to use. This must be done
- # <after>defining the interface, and <before>any data is sent to
- # the TNC (for example, by the smtp and pop kick commands below).
- # These commands will do that for a TNC2:
- comm ax0 "kiss on"
- comm ax0 "reset"
-
- # kick the smtp and POP servers at startup. Only uncomment the
- # "pop kick" line if you've defined a POP server above.
- smtp kick
- #pop kick
-
- # GRINOS (but not other versions) can define the function
- # keys with macros to make things a bit easier. Here are a
- # couple of examples. Note that each command must end with
- # a "\n" to signify a carriage return. The numbers
- # represent the keys; 59 - 68 for F1- F10 (though F10 can't
- # be redefined; it's always the escape key), 84 - 93 for
- # shiftF1 - shift F10, 94 - 103 for ctrlF1 - ctrlF10, 104 -
- # 113 for altF1 - altF10.
- fkey 59 "tcp status\n"
- fkey 60 "mem status\n"
- fkey 61 "status\n"
-
- # THE END
-
- APPENDIX C
- Designing ATTACH Commands
-
- NOS supports a number of versions of the attach command to deal
- with different hardware. We'll discuss three of them here: asy,
- used for serial port connections; pi, used to connect to the Ottawa
- PI card; and packet, used to interface to hardware supporting the
- FTP, Inc., packet driver protocol. As usual, this discussion covers
- the basics; see the NOS reference manual for details on all the
- many options.
-
- Hosts normally have a separate IP address for each interface. If
- you are running more than one interface, you can include that
- interface's IP address (in [xx.xx.xx.xx] form) at the end of the
- attach command.
-
- The asy version provides an interface to a standard PC serial port.
- The syntax is:
-
- attach asy <ioaddr> <vector> <mode> <if> <bufsize>
- <mtu> <speed>
-
- In English, these parameters are:
-
- ioaddr -- the address of the COM port being used.
- COM1 is usually 0x3f8 and COM2 is usually 0x2f8.
- COM3 and COM4 aren't standardized; using them will
- require looking at the documentation for your serial card,
- and probably some experimentation.
-
- vector -- the IRQ used by the hardware. COM1 is usually
- 4, and COM2 is usually 3. Again, COM3 and COM4
- vary.
-
- mode -- this specifies the nature of the interface. ax25 is
- for a connection to a KISS TNC, slip for a hardwired
- connection to another host, ppp for a dial-up connection,
- and nrs is for attaching a NOS station to a NetRom node.
-
- if -- the interface name. The convention is to use ax0,
- ax1, etc., for KISS interfaces.
-
- bufsize -- the buffer for incoming data, in bytes. Usually
- a value of 1024 is more than sufficient for a 1200 baud
- channel.
-
- mtu -- the maximum transmission unit size, in bytes. See
- the discussion in the main text on this subject.
-
- speed -- the speed of the serial (not radio) link, in baud.
- The best setting for this will depend on the speed of your
- computer, but generally two to four times the radio
- speed is adequate.
-
- Some sample attach asy commands are:
-
- # COM1, KISS TNC as ax0, MTU 256, 4800 BAUD
- attach asy 0x3f8 4 ax25 ax0 1024 256 4800
-
- # COM2, KISS TNC as ax1, MTU 256, 2400 BAUD
- attach asy 0x2f8 3 ax25 ax1 1024 256 2400
-
- # SLIP link, COM1 as sl0, MTU 256, 9600 BAUD
- attach asy 0x3f8 4 slip sl0 1024 256 9600
-
- The Ottawa PI card is a plug-in board for PCs designed for high-
- speed performance. It has two ports, one DMA driven for high
- speed and the other interrupt driven. The attach syntax is:
-
- attach pi <ioaddr> <vector> <DMA chn> <mode> <name>
- <bufsize> <mtu> <speed a> <speed b>
-
- A sample attach command (using the PI's default jumper settings)
- is:
-
- attach pi 380 7 1 ax25 pi0 1750 1024 0 1200
-
- In this example, the interface name for the DMA port is "pi0a" and
- the second port is "pi0b". Because the port a speed is 0, the PI
- card expects the modem to provide its own clocking. The PI
- attach syntax is explained in the manual provided with the card.
-
- Finally, the packet interface is used to connect to ethernet cards
- and other hardware that supports the FTP, Inc. "packet driver"
- standard. There's a packet driver for the PI card. The syntax is:
-
- attach packet <ioaddr> <vector> <if> <bufsize> <mtu>
-
- In this case, ioaddr and vector need to match those used for the
- packet TSR that supports the hardware. bufsize is the number of
- packets (not bytes) that may be outstanding. For ethernet, the
- standard mtu is 1500.
-
- APPENDIX D
- The DOMAIN.TXT File
-
-
- # The domain.txt file contains mappings between hostnames
- # and IP addresses. The file can be quite complex, but
- # basic entries usually resemble this.
-
- # Fields are separated by tabs or spaces.
-
- # These are normal address records. The first field is the
- # hostname. The second field is a "time to live" value
- # returned by the name server. If you manually create an
- # entry, you can leave this field blank. The third field
- # is always "IN" to signify these are internet addresses.
- # The fourth field is "A" to signify an address record. The
- # last field is the address.
-
- k8gkh.ampr.org.9886 IN A 44.70.12.31
- ag9v.ampr.org. 3584 IN A 44.70.12.34
-
- # This is a "canonical name" (CNAME) record that maps an
- # alias to an official hostname.
-
- server.ampr.org. 3599 IN CNAME ag9v.ampr.org.
-
- APPENDIX E
- Sample FTPUSERS File
-
- # This file establishes ftp user permissions. Fields are
- # separated by exactly one space. The privileges value is a
- # bitmask. The only values significant for ftp are:
-
- # 1 - read only
- # 3 - read/write
- # 7 - read/write/overwrite/delete
-
-
- anonymous * /pub 1 # no password, read only in /pub
- friend foobar /pub 3 # read/write privileges in /pub
- spouse snoogums / 7 # read/write/delete everywhere
-
- APPENDIX F
- Making Your TNC Talk in KISS MODE
-
- Once NOS is installed and your configuration files set, you need to
- do one more thing: get your TNC talking to your computer in KISS
- (Keep It Simple, Stupid) mode. KISS is a special protocol that lets
- your computer do the work of processing packets; the TNC does
- only the very low-level packet assembly and disassembly
- functions. Nearly all TNCs support KISS in one way or another.
-
- Typically, you'll need to issue commands to the TNC to set the
- serial line baud rate to the same speed as you've specified in the
- attach command, to 8 bit data, and to no parity. Then, issue the
- KISS command (on a TNC2, kiss on), and the TNC's software
- reset command. After that, you won't be able to talk to your TNC
- via the terminal program, but NOS will be able to. (And don't
- worry, you can easily return the TNC to normal mode if you want
- to.) Once you've done this, you're set to run NOS.
-
- One trick that grinos supports is the ability to send commands to
- the TNC during startup. The comm command will send a string of
- text to the named interface. For example, to force a Kantronics
- DataEngine or KAM into KISS mode every time you start NOS,
- include the following commands in AUTOEXEC.NOS (after you've
- defined the interface with the attach command):
-
- comm ax0 "interface kiss"
- comm ax0 "reset"
-
- Note that surrounding the text with quote characters will preserve
- spaces in the command.
-
- Appendix G
- A Sample BM.RC File
-
- # BM.rc
-
- # your hostname -- note that for mail we <don't> put a trailing
- period at
- # the end of the FQDN.
- host ag9v.ampr.org
-
- # the user name (one host can receive mail for several users);
- # usually your callsign
- user ag9v
-
- # your full name, for the message "From:" line
- fullname John Ackermann
-
- # if you want to have replies sent to another host, because, for
- # example, you are using a POP server, this line specifies where
- # replies should go
- reply ag9v@ag9v.ampr.org
-
- # for faster screen writes on the pc, use direct video, not bios
- screen direct
-
- # if you want to use an editor different than BM's built-in one
- edit ed
-
- # put saved messages here; note "/" instead of "\"
- mbox c:/folder/mbox
-
- # save a copy of outbound mail here
- record c:/folder/outmail
-
- # folder for your mail
- folder c:/folder
-
- # maximum number of messages that can be pending
- maxlet 200
-
-